home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr48 / pas_0593.zip / MCGA-2.TXT < prev    next >
Text File  |  1993-05-30  |  6KB  |  103 lines
  1.                            MCGA Graphics Tutorial
  2.                                  Lesson #2
  3.                                 by Jim Cook
  4.  
  5. I have to apologize a little bit.  The first lesson contained code for
  6. setting a pixel by directly altering video memory.  This probably was a
  7. strange sight for those of you that do not understand video memory, how
  8. it's layed out and how to address it.  I do hope you did get excited by
  9. workable code in the first lesson.
  10.  
  11. Video memory in the MCGA Mode we are using is far simpler to understand
  12. than even Text mode display memory.  Those of you that know all about
  13. text screen addressing, just scoffed.  No, seriously, it is as simple.
  14. I will try to make this easy to understand, because it really is.
  15.  
  16. There is an area in your computer's memory that holds the program that is
  17. currently running, as well as, COMMAND.COM and other system drivers.   s
  18. Most of you realize that there is also a section of memory that holds
  19. all of the information regarding your video screen.  In the MCGA #1 you
  20. will notice that we changed the value of a byte in memory to change the
  21. color of a pixel on the screen.  This may seem magical to some, but it
  22. really isn't.  The logic driving a video card is simply this:
  23.  
  24.     1. Scan video memory and write the bytes you see there
  25.        to the screen.
  26.     2. Repeat Step 1.
  27.  
  28. Unlike COMMAND.COM and the program that's running, whose starting address
  29. in memory could be different depending on a multitude of factors, video
  30. memory is always at the same location.  In MCGA mode, video memory begins
  31. at the 655,360th byte of computer memory.  You may say that my computer
  32. only has 655,360 bytes of memory total (640K).  Where does that memory
  33. reside?  Don't quote me on this, but I believe that the video memory
  34. wholly resides on your graphics card.
  35.  
  36. So, the graphics card is responsible for scanning this piece of memory
  37. many times per second, and displaying on the screen whatever color
  38. values are stored starting at byte 655,360.  By the way, in hex (base 16)
  39. that number is $A0000, and we'll refer to it like that from now on.
  40. These color values that I referred to are numbers from 0 to 255.  If we
  41. store the number 0 in every byte of screen memory and the computer
  42. thinks that 0 means black, which it usually does, the screen will
  43. instantly clear to black.  That's how you do a screen clear in MCGA.
  44.  
  45. The resolution of our screen is 320 pixels horizontal by 200 pixels
  46. vertical.  That makes up a total of 64000 pixels per screen.  A normal
  47. text screen only has 4000 bytes of screen memory, so you can see why we
  48. sometimes use assembly language.  So, a very prehistoric screen clear
  49. procedure could look something like:
  50.  
  51.                 Procedure ClearScreen (Color:Byte);
  52.                 var
  53.                   I  :  Word;
  54.                 begin
  55.                   For I := 0 to 64000 do
  56.                     Mem [$A000:I] := Color;
  57.                 end;
  58.  
  59. You'll notice I had to break the number $A0000 into two numbers.  This
  60. is called segment-offset addressing, and it is a throwback to the days
  61. when the engineers felt we would never need more than 640K of memory.
  62. Let me briefly explain.  The memory address $A0000 and $A000:0000 are
  63. synonymous.  To compute a virtual address from a seg:ofs address you
  64. perform the calcualtion: virtual := seg * 16 + ofs.  This lets a
  65. programmer access over 1 meg of memory using 2 word size values.  Don't
  66. ask...
  67.  
  68. OK.  Since we are pretty much all hackers at heart and I don't have a
  69. chalkboard, I'll illustrate video memory:
  70.               0   1   2   3   4   5   --->  up to pixel 319
  71.             +---+---+---+---+---+---+---+---+---+---+---+---+--
  72.         0   + 0 | 1 | 2 | 3 | 4 | 5 |   |   |   |   |   |   |
  73.             +---+---+---+---+---+---+---+---+---+---+---+---+--
  74.         1   +320|321|322|323|324|   |   |   |   |   |   |   |
  75.             +---+---+---+---+---+---+---+---+---+---+---+---+--
  76.         2   +640|641|642|643|   |   |   |   |   |   |   |   |
  77.             +---+---+---+---+---+---+---+---+---+---+---+---+--
  78.         3   +   |   |   |   |   |   |   |   |   |   |   |   |
  79.  
  80. Assume, (I know, bad word), that this is a extreme closeup of the upper
  81. left corner of a MCGA screen.  As a matter of fact the box 0 is the
  82. first pixel (the uppermost leftest most pixel) on the screen.  Say, we
  83. want to make it white.  In the default palette the color white is 255.
  84. All we have to do is say:       Mem [$A000:0000] := 255;
  85. If we want to make the pixel below it white also, we type :
  86.                                 Mem [$A000:0320] := 255;
  87. As you can see, segment:offset addressing actually comes in handy in
  88. addressing pixels on the screen.  Since there are 320 pixels across and
  89. 200 Pixels up and down, the following formula returns the address of any
  90. pixel on the MCGA screen:       (Y * 320) + X
  91. This is assuming the upperleft pixel is (0,0) and the lower right pixel
  92. is (319,199), and we will.
  93.  
  94. Understanding screen addresses is essential to comprehending any of the
  95. code we will be developing, so if a point is not clear...POST a message.
  96. Don't be bashful about asking questions.  Just a quick point...I did not
  97. go to school to learn this.  This is something everyone can learn.
  98. Graphics is a subject that a lot gets written about, but not the guts of
  99. programming it.  Many of you may opt for the easy way out (canned
  100. libraries) but to really understand your computer you have to know
  101. what's going on under the hood.  Also, for laughs, try implementing a
  102. good animation program or GUI with the BGI.
  103.